4 Точки внешней интеграции

Глава 4: Точки внешней интеграции

В данной главе описываются точки интеграции протокола CAP с внешними системами, определяются границы ответственности, направления взаимодействия и требования к протоколам связи для каждой точки интеграции. Протокол CAP не является изолированной системой — он должен взаимодействовать с iFay_Runtime, операционной системой терминала, аппаратными драйверами и Registration_Authority для совместного управления полномочиями терминала. Понимание границ интерфейсов и способов взаимодействия этих точек интеграции является предпосылкой для корректной реализации протокола CAP системными интеграторами.

4.1 Интеграция с iFay_Runtime

iFay_Runtime является средой выполнения Fay (iFay или coFay), отвечающей за управление жизненным циклом и планирование экземпляров Fay. С точки зрения протокола CAP, iFay_Runtime является инициатором запросов на управление — когда Fay необходим доступ к ресурсам терминала, iFay_Runtime от его имени направляет запрос на проверку авторизации к уровню протокола CAP.

Обязанности интеграции:

• Инициирование запросов на управление: iFay_Runtime от имени Fay направляет запрос на проверку авторизации в Protocol_Engine, содержащий идентификатор Fay, целевой Terminal_Resource и учётные данные авторизации (Authorization_Descriptor или Trusted_Ticket)
• Управление жизненным циклом Fay: iFay_Runtime отвечает за запуск, приостановку, возобновление и завершение экземпляров Fay. При завершении экземпляра Fay iFay_Runtime уведомляет Protocol_Engine об освобождении всех активных Session, удерживаемых данным Fay
• Поддержание канала обнаружения активности: iFay_Runtime отвечает за поддержание постоянного соединения между Fay и терминалом и отправку heartbeat-сообщений на уровне приложения с настроенным интервалом, обеспечивая нормальную работу механизма Liveness_Detection
• Получение уведомлений о состоянии сеансов: Protocol_Engine уведомляет iFay_Runtime об изменениях состояния Session (успешное создание, запрос на передачу, принудительное завершение), а iFay_Runtime передаёт эту информацию соответствующему экземпляру Fay

Направление взаимодействия: Двунаправленное (Bidirectional)

iFay_Runtime направляет запросы к уровню протокола CAP (проверка авторизации, освобождение сеанса, отправка heartbeat), а уровень протокола CAP возвращает ответы и отправляет push-уведомления iFay_Runtime (результаты проверки, изменения состояния сеансов, запросы на передачу).

Требования к протоколу связи:

• Между iFay_Runtime и Protocol_Engine используется модель запрос-ответ на основе сообщений; формат сообщений соответствует определению Schema протокола CAP
• Канал обнаружения активности требует поддержки постоянного соединения для реализации heartbeat на уровне приложения и push-уведомлений о состоянии в реальном времени
• Канал связи должен поддерживать шифрование TLS, обеспечивая конфиденциальность и целостность учётных данных авторизации и информации о сеансах при передаче
• Формат сериализации сообщений должен соответствовать файлу определения Schema (schema.json), обеспечивая межреализационную совместимость

4.2 Интеграция с операционной системой терминала

Операционная система терминала является управляющей стороной Terminal_Resource, отвечающей за унифицированное управление программными и аппаратными ресурсами терминала. Протокол CAP через интеграцию с операционной системой преобразует результаты проверки авторизации в фактический контроль доступа к ресурсам — операционная система на основании инструкций Protocol_Engine разрешает или запрещает доступ Fay к определённым ресурсам.

Обязанности интеграции:

• Выполнение контроля доступа к ресурсам: Операционная система на основании инструкций контроля доступа, выданных Protocol_Engine, на системном уровне разрешает или блокирует доступ Fay к Terminal_Resource. Это включает контроль доступа к файловой системе, управление правами процессов, разрешения на доступ к устройствам и т.д.
• Отчёт о состоянии ресурсов: Операционная система сообщает Protocol_Engine текущее состояние Terminal_Resource (доступен, занят, недоступен), позволяя Protocol_Engine принимать точные решения о распределении ресурсов
• Изоляция среды выполнения: Операционная система обеспечивает изоляцию на уровне процессов или песочницы для операций различных Fay, гарантируя, что операции одного Fay не повлияют на доступ к ресурсам других Fay или пользователей-людей
• Перенаправление событий ресурсов: При изменении состояния Terminal_Resource (например, отключение оборудования, сбой программного обеспечения) операционная система перенаправляет уведомление о событии в Protocol_Engine, инициируя соответствующий процесс завершения Session или освобождения ресурсов

Направление взаимодействия: Двунаправленное (Bidirectional)

Уровень протокола CAP направляет операционной системе инструкции контроля доступа и запросы состояния ресурсов, а операционная система сообщает уровню протокола CAP о состоянии ресурсов и перенаправляет события ресурсов.

Требования к протоколу связи:

• Между уровнем протокола CAP и операционной системой используется механизм локального межпроцессного взаимодействия (IPC); конкретный способ зависит от платформы операционной системы (например, Unix Domain Socket, Named Pipe, D-Bus и т.д.)
• Инструкции контроля доступа должны выполняться в режиме синхронного вызова, обеспечивая немедленное получение Protocol_Engine результата выполнения инструкции
• Уведомления о событиях ресурсов используют асинхронный push-режим; операционная система активно уведомляет Protocol_Engine при изменении состояния ресурсов
• Интерфейс связи должен соответствовать нативной модели безопасности операционной системы, обеспечивая, что только авторизованный процесс Protocol_Engine может выдавать инструкции контроля доступа

4.3 Интеграция с аппаратными драйверами

Аппаратные драйверы являются интерфейсом доступа к аппаратным Terminal_Resource (таким как камера, микрофон, GPS-модуль, устройства хранения и т.д.). Протокол CAP через интеграцию с аппаратными драйверами реализует детализированное управление полномочиями для аппаратных ресурсов. Аппаратные драйверы в системе интеграции протокола CAP находятся ниже операционной системы, обеспечивая низкоуровневый доступ к аппаратным ресурсам.

Обязанности интеграции:

• Предоставление интерфейса доступа к аппаратным ресурсам: Аппаратные драйверы предоставляют уровню протокола CAP описание возможностей аппаратных ресурсов и операционный интерфейс, позволяя Protocol_Engine понимать поддерживаемые режимы доступа аппаратных ресурсов (read, write, execute, configure)
• Выполнение контроля доступа на аппаратном уровне: Аппаратные драйверы на основании управляющих инструкций, переданных Protocol_Engine через операционную систему, выполняют разрешение или запрет доступа на аппаратном уровне. Например, разрешение или запрет Fay на включение камеры, доступ к микрофону
• Отчёт о состоянии оборудования: Аппаратные драйверы сообщают вышестоящему уровню о состоянии подключения, рабочем состоянии и информации об ошибках аппаратных устройств; эта информация в конечном итоге передаётся в Protocol_Engine для принятия решений по управлению Session
• Поддержка эксклюзивного управления аппаратными ресурсами: Для аппаратных ресурсов, требующих эксклюзивного доступа (например, вывод видеопотока камеры), аппаратные драйверы на низком уровне обеспечивают, что в один момент времени только одна сторона управления может монопольно использовать ресурс

Направление взаимодействия: Однонаправленное (Unidirectional) — Уровень протокола CAP → Аппаратные драйверы

Уровень протокола CAP через операционную систему направляет управляющие инструкции аппаратным драйверам; информация о состоянии аппаратных драйверов передаётся вверх через уровень управления устройствами операционной системы. Уровень протокола CAP не устанавливает прямой канал связи с аппаратными драйверами, а взаимодействует опосредованно через операционную систему. Путь отчёта о состоянии оборудования: аппаратный драйвер → операционная система → Protocol_Engine, что является частью точки интеграции с операционной системой (4.2).

Требования к протоколу связи:

• Уровень протокола CAP не взаимодействует напрямую с аппаратными драйверами; всё взаимодействие осуществляется опосредованно через интерфейс управления устройствами операционной системы (например, DeviceIoControl, ioctl, sysfs и т.д.)
• Описание возможностей аппаратных ресурсов должно соответствовать унифицированному формату описания ресурсов, позволяя Protocol_Engine единообразно управлять различными типами аппаратных ресурсов
• Аппаратные драйверы должны поддерживать стандартный интерфейс контроля доступа к устройствам, предоставляемый операционной системой, обеспечивая применение инструкций контроля доступа протокола CAP на аппаратном уровне
• Для высокочувствительных аппаратных ресурсов (таких как камера, микрофон) аппаратные драйверы должны поддерживать механизм блокировки доступа на аппаратном уровне, предотвращая обход контроля доступа на уровне операционной системы

4.4 Интеграция с Registration_Authority

Registration_Authority (Регистрационный орган) является ключевым компонентом инфраструктуры доверия протокола CAP, отвечающим за управление регистрацией аппаратного обеспечения, программного обеспечения и операционных систем терминалов, а также за распространение ключей проверки (Verification_Key) на терминалы. Verification_Key, получаемый терминалом от Registration_Authority, является якорем доверия для офлайн-проверки авторизации — без легитимного Verification_Key терминал не может проверить цифровую подпись Authorization_Descriptor.

Обязанности интеграции:

• Регистрация терминала: Терминальное устройство (включая аппаратное обеспечение, операционную систему и клиентское программное обеспечение) проходит регистрацию через Registration_Authority, получая уникальный идентификатор терминала и начальную конфигурационную информацию
• Распространение Verification_Key: Registration_Authority распространяет Verification_Key на зарегистрированные терминалы; терминал использует этот ключ для проверки цифровой подписи Authorization_Descriptor. Процесс распространения ключей должен осуществляться через безопасный канал для предотвращения подмены или перехвата ключей
• Обновление и ротация ключей: Когда Verification_Key требует обновления (например, истечение срока действия ключа, смена издателя), Registration_Authority отвечает за отправку нового ключа на терминалы и координацию плавного перехода в процессе ротации ключей
• Управление статусом регистрации: Registration_Authority поддерживает статус регистрации терминалов, включая регистрацию, приостановку и аннулирование. Статус регистрации терминала влияет на его возможность получать обновления Verification_Key и участвовать в процессе проверки авторизации протокола CAP

Направление взаимодействия: Однонаправленное (Unidirectional) — Registration_Authority → Терминал

Registration_Authority распространяет Verification_Key и регистрационную информацию на терминалы; терминалы являются пассивными получателями. Терминалы не направляют запросы на проверку авторизации и не сообщают о рабочем состоянии Registration_Authority — проверка авторизации терминала полностью выполняется локально (с использованием ранее распространённого Verification_Key), без необходимости поддержания связи с Registration_Authority в реальном времени. Запрос регистрации, направляемый терминалом в Registration_Authority, является одноразовым процессом инициализации и не относится к штатному взаимодействию во время работы протокола CAP.

Требования к протоколу связи:

• Связь между Registration_Authority и терминалом должна осуществляться через безопасный канал (например, TLS/mTLS), обеспечивая конфиденциальность и целостность Verification_Key при передаче
• Протокол распространения ключей должен поддерживать два режима: офлайн-предустановку и онлайн-обновление. Терминал при выпуске может содержать предустановленный начальный Verification_Key, а последующие обновления ключей получать через онлайн-канал
• Сообщения об обновлении ключей должны содержать номер версии и время вступления в силу, поддерживая плавный переходный период между старым и новым ключами для предотвращения прерывания проверки авторизации при ротации ключей
• Registration_Authority должен предоставлять механизм подтверждения распространения ключей, обеспечивая успешное получение и сохранение терминалом нового Verification_Key

4.5 Обзор направлений взаимодействия и протоколов связи точек интеграции

В следующей таблице обобщена информация о точках интеграции протокола CAP с 4 внешними системами, включая направления взаимодействия и требования к протоколам связи:

Точка интеграции	Внешняя система	Направление взаимодействия	Требования к протоколу связи
4.1	iFay_Runtime	Двунаправленное (Bidirectional)	Модель запрос-ответ на основе сообщений; поддержка постоянного соединения (обнаружение активности); шифрование TLS; формат сообщений соответствует определению Schema CAP
4.2	Операционная система терминала	Двунаправленное (Bidirectional)	Локальное межпроцессное взаимодействие (IPC); синхронный вызов + асинхронный push событий; соответствие нативной модели безопасности ОС
4.3	Аппаратные драйверы	Однонаправленное (CAP → Аппаратные драйверы)	Опосредованная связь через интерфейс управления устройствами ОС; унифицированный формат описания ресурсов; поддержка блокировки доступа на аппаратном уровне
4.4	Registration_Authority	Однонаправленное (RA → Терминал)	Безопасный канал TLS/mTLS; поддержка офлайн-предустановки и онлайн-обновления; управление версиями ключей и плавная ротация

Пояснение к направлениям взаимодействия:

• Двунаправленное (Bidirectional): Между уровнем протокола CAP и внешней системой существует двунаправленное взаимодействие запрос-ответ или уведомление о событиях; обе стороны могут инициировать связь
• Однонаправленное (Unidirectional): Информационный поток направлен только от одной стороны к другой. В п. 4.3 уровень протокола CAP через операционную систему направляет инструкции аппаратным драйверам (без прямой связи); в п. 4.4 Registration_Authority распространяет ключи и регистрационную информацию на терминалы (терминалы являются пассивными получателями)

Принципы проектирования протоколов связи:

• Безопасность: Все каналы связи, связанные с передачей учётных данных авторизации и ключей, должны быть зашифрованы для предотвращения атак «человек посередине» и утечки информации
• Адаптация к платформе: Интеграция с операционной системой и аппаратными драйверами использует нативные интерфейсы платформы, обеспечивая совместимость с различными операционными системами
• Совместимость: Интеграция с iFay_Runtime и Registration_Authority использует стандартизированный формат сообщений (на основе Schema CAP), обеспечивая совместимость между различными реализациями
• Отказоустойчивость: Протоколы связи должны поддерживать механизмы повторных попыток и деградации, обеспечивая нормальную работу основных функций протокола CAP (особенно офлайн-проверки авторизации) при прерывании связи